Pull Request Test Coverage Report for Build 543

• 6 of 6 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.06%) to 88.44%

Totals
Change from base Build 539:	0.06%
Covered Lines:	829
Relevant Lines:	916

💛 - Coveralls

I think this is a nice idea. I'm curious what others will think

@jasonLaster @MotorHeat rather than trying both LEAST_UPPER_BOUND and GREATEST_LOWER_BOUND, might it instead make sense to return the mid point during the binary search process rather than failure? I'm not sure how to read the WASM version of the module, but looking at the older version of the library, it looks like the search logic is something along these lines:

    if (aBias == exports.LEAST_UPPER_BOUND) {
      return aHigh < aHaystack.length ? aHigh : -1;
    } else {
      return mid;
    }

Where if aHigh, as an example, is greater than our haystack we return a failure, rather than simply returning the closest element mid.

Am I missing something, or would it be good to have a mode that's more resilient like this?

I'm not sure how to read the WASM version of the module,
The WASM code is here:
https://github.com/fitzgen/source-map-mappings/blob/197660faf3dd1167c643797a5ed62cb687482c54/src/lib.rs#L346-L356

Hi @MotorHeat @bcoe, thanks for the patch.

I'm trying to revive the maintenance of this package....
Would you have any example where this code fails?
It would help write a test to cover this and better understand if we should go for the mid point or the left or right search.

@ochameau hey 👋, sorry I've paged this problem out of my brain 😆

I think it related to this code I was writing a few years ago, to try to make a best effort guess at what line to remap to.